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DESCRIPTIVE  ANALYSIS  FOR  COMPUTER-BASED  DECISION  SUPPORT 


Abstract 

This  article  studies  the  issue  of  descriptive  analysis  for  Decision  Support  Systems 
(DSS).  Much  of  the  DSS  research  literature  concentrates  on  the  procedural  aspects  of 
building  support  systems  rather  than  on  the  substantive  issues  of  their  content.  If  we  are 
to  expand  further  our  knowledge  of  DSS.  however,  it  is  important  to  complement  our 
understanding  of  the  process  of  DSS  development  with  a  means  for  describing  and 
differentiating  DSS.  In  particular,  a  descriptive  mechanism  should  pay  careful  attention  to 
those  features  of  DSS  that  determine  the  effects  a  support  system  has  on  the 
decision-making  processes  of  its  users. 

A  three-tiered  approach  to  describing  DSS  is  proposed,  consisting  of  the  following 
sequence  of  analytical  levels;  functional  capabilities,  user  views  of  system  components,  and 
system  attributes  (restrictiveness,  guidance,  and  focus).  Moving  from  the  first  through  the 
third  tiers,  increasing  attention  is  paid  to  examining  DSS  in  their  entirety  and  to 
considering  their  effects  on  decision-making  processes.  Implications  for  further  research 
are  highlighted. 


DESCRIPTIVE  ANALYSIS  FOR  COMPUTER-BASED  DECISION  SUPPORT 


For  Decision  Support  Systems  (DSS)  to  continue  to  flourish  as  a  field  of  research,  it 
is  essential  that  we  be  able  to  describe  the  objects  of  our  study,  namely,  Decision  Support 
Systems.  Just  as  physicists  employ  mathematical  equations  and  chemists  enlist  molecular 
models  as  descriptive  tools,  so  too  can  DSS  researchers  make  good  use  of  a  means  of 
describing  the  systems  they  study.  Indeed,  virtually  every  area  of  DSS  research  activity 
could  benefit  from  a  good  descriptive  mechanism  for  DSS. 

Consider,  for  example,  research  concerning  DSS  analysis  and  design.  One  of  the 
central  concepts  in  the  literature  is  that  DSS  must  be  tailored  to  the  specific 
decision-making  environments  they  support.  It  is  useful,  therefore,  to  think  of  systems 
analysis  and  design  as  a  matching  process,  a  function  that  accepts  decision-making 
environments  as  inputs  and  produces  corresponding  computer-based  information  systems  as 
outputs  (see  Figure  1).  The  goal  is  to  create  or  to  select  that  one  computer-based  system 
from  the  universe  of  possible  systems  that  best  meets  the  needs  of  the  environment.  The 
DSS  analysis  and  design  processes  could  be  both  more  efficient  and  more  effective  if 
meaningful  knowledge  bases  could  be  used  to  support  this  effort.  These  knowledge  bases 
must 


'  identify  and  describe  the  key  characteristics  of  people,  tasks,  and  organizational 
settings  to  be  considered; 

•  describe  how  DSS  differ  from  one  another  and  how  those  differences  affect  the 
way  decisions  are  likely  to  be  made;  and 

‘  prescribe  a  mapping  that  translates  characteristics  of  environments  into 
characteristics  of  the  systems  that  support  them. 


The  challenge  for  DSS  researchers  is  to  create  and  expand  these  DSS  knowledge  bases. 
The  ultimate  goal--not  yet  on  the  horizon  and  perhaps  not  fully  attainable- -is  a 
prescriptive  mapping  from  environments  to  systems.  Before  we  can  even  consider  such 
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1  Figure  i 

Simple  Model  of  Systems  Analysis  and  Design 
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prescription,  however,  we  must  first  have  more  meaningfui  description.  The  immediate 
focus  of  research  attention  should,  therefore,  be  on  developing  appropriate  means  for 
describing  and  differentiating  environments  and,  especially,  systems. 

To  date,  a  relatively  small  share  of  DSS  research  has  addressed  these  issues.  The 
most  widely  read  portion  of  DSS  research  has  addressed  the  'procedural*  issues  of  building 
systems  rather  than  the  ’substantive*  questions  concerning  their  content.  For  instance,  the 
terms  ’Adaptive  Design*  (Keen,  1980),  ’Middle-Out  Design*  (Ness,  1975;  Hurst  et  al., 

1983),  ’Evolutionary  Development*  (Grajew  and  Tolovi,  1978;  Hurst  et  al.,  1983),  and 
others  like  them  dominate  the  DSS  literature.  While  the  concept  of  involving  users  in  an 
evolutionary  development  process  is  no  doubt  important,  the  time  has  now  come  to  ask  the 
question:  What  do  we  do  substantively  as  we  proceed  to  design  in  an  adaptive, 
middle-out,  and  evolutionary  manner? 

Within  the  relatively  small  segment  of  the  DSS  literature  that  is  descriptive, 
decision-making  environments  have  received  far  greater  attention  than  have  Decision 
Support  Systems  themselves.  In  fact,  a  number  of  promising  characteristics--for  instance, 
task  structure  (Mason  and  Mitroff,  1973;  Lerch  and  Mantei,  1984),  task  interdependency 
(Hackathorn  and  Keen,  1981),  and  organizational  style  (Huber,  198l)--have  been  proposed 
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for  categorizing  environments.  To  a  large  extent,  however,  these  characteristics  have 
remained  loose  ends  in  the  literature.  They  have  been  introduced — and  in  some  cases 
widely  cited--but  never  developed.  There  is  little  to  indicate  how  these  environmental 
differences  might  translate  into  differences  in  systems.  We  are  left  to  conclude  that  the 
mapping  would  be  an  identity:  Type  "X"  systems  would  be  built  for  type  "X" 
environments. 

Perhaps  the  reason  these  characteristics — the  inputs  to  the  design  process — could  not 
be  pushed  further  is  that  so  little  attention  has  been  paid  to  the  outputs,  the  Decision 
Support  Systems  themselves.  Other  than  Alter’s  (1980)  now  dated  taxonomy,  we  have  done 
relatively  little  to  describe  how  DSS  differ  from  one  another.  In  particular,  we  have  not 
confronted  what  ought  to  be  the  central  substantive  issue  in  DSS  design:  how  features  of 
DSS  affect  decision-making  processes. 

All  in  all,  it  is  quite  surprising  that  the  description  and  differentiation  of  Decision 
Support  Systems  have  received  so  little  research  attention.  The  purpose  of  this  study  is  to 
begin  to  remedy  that  situation  by  exploring  ways  in  which  Decision  Support  Systems  can 
be  described  and  compared.  A  three-tiered  approach  will  be  employed. 

1.  Objectives 

One  can  imagine  any  number  of  different  schemes  for  describing  a  particular 
Decision  Support  System.  What,  then,  are  the  criteria  against  which  a  descriptive 
mechanism  should  be  judged?  Generally  speaking,  the  objective  is  to  enlighten  both 
research  and  practice.  That  is,  the  descriptive  mechanism  should  provide  a  better 
understanding  of  the  object  under  study--in  this  case,  DSS--and  it  should  also  facilitate 
further  research,  thus  serving  as  the  basis  for  still  greater  understanding  in  the  future. 

More  specifically,  a  good  descriptive  mechanism  will  have  a  number  of  desirable 
properties.  First,  the  mechanism  should  be  applicable  to  all  aspects  of  the  study  of  DSS. 
Every  DSS  research  area  depends  upon  having  some  means  of  describing  DSS,  and  every 
research  area  can  benefit  from  a  good  descriptive  mechanism.  Different  research  questions. 
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however,  may  require  different  types  of  descriptions.  An  important  objective,  therefore,  is 
that  the  descriptive  mechanism  be  sufficiently  complete  to  serve  the  full  range  of  DSS 
research  needs. 

Having  a  common  mechanism  for  describing  DSS  can  facilitate  communication  among 
researchers  and  can  contribute  to  establishing  a  cumulative,  integrated  research  base.  For 
researchers  working  on  the  same  or  closely  related  problems,  sharing  the  same  method  of 
description  can  make  it  easier  to  compare  findings  with  one  another.  For  researchers 
concentrating  on  different  topics,  the  common  mechanism  provides  a  means  for  linking  the 
various  components  of  DSS  research  to  construct  a  more  complete  picture  of  the  field. 

The  descriptive  mechanism  must  also  link  researchers  with  practitioners.  Researchers 
must  be  able  to  use  it  as  a  vehicle  to  convey  their  findings  to  practitioners  concerning  the 
appropriate  use  of  new  and  existing  decision-aiding  techniques.  The  descriptive  schema 
must  serve  ultimately  as  the  basis  for  a  prescriptive  mapping  from  characteristics  of 
decision-making  environments  to  features- -that  is,  characteristics- -of  Decision  Support 
Systems.  In  the  meantime,  the  schema  can  enlighten  DSS  practice  by  helping  implementors 
identify  the  key  elements  in  the  design  and  selection  of  DSS. 

Simply  being  able  to  describe  Decision  Support  Systems  is  not  sufficient.  A  good 
mechanism  will  also  help  differentiate  DSS  from  one  another,  often  an  important  activity  in 
DSS  research.  Consider  Figure  2,  which  augments  Figure  1  to  include  system  use  as  well 
as  systems  analysis  and  design.  The  inputs  to  the  process  of  system  use  are  the 
decision-making  environment  and  the  DSS,  and  the  outputs  are  decisions.  The  various 
entities,  processes,  and  relationships  in  the  diagram  suggest  numerous  research  questions, 
many  of  which  depend  upon  the  ability  to  differentiate  DSS  appropriately.  Among  these 
questions  are  the  following: 

'  Do  different  analysis  and  development  processes  systematically  produce  DSS  with 
different  characteristics? 

'  Should  different  types  of  decision-making  environments  be  supported  by  DSS  with 
different  characteristics? 
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*  Does  the  use  of  DSS  with  different  characteristics  systematically  lead  to  different 
decision-making  behavior  and/or  different  decisions? 

•  Are  DSS  with  some  characteristics  more  likely  to  be  used  than  those  with  others? 

A  necessary  foundation  for  studying  each  of  these  problems  is  a  means  of  describing  not 
just  DSS,  but  differences  among  DSS. 

Most  of  the  aforementioned  objectives  apply  equally  well  to  describing  any 
computer-based  information  system.  The  uniqueness  of  describing  systems  that  support 
decision  makers  is  found  in  the  need  to  present  the  decisional  qualities  of  the  system. 


Figure  2 

Schematic  Interpretation  of  Some  DSS  Research  Issues 
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That  is,  a  useful  schema  must  capture  how  a  system  is  likely  to  affect  the  way  in  which 
decisions  are  made  and  must  distinguish  systems  in  terms  of  their  likely  effects  on 
decision-making  behavior.  Indeed,  understanding  how  Decision  Support  Systems  affect 
managerial  decision  making  is  and  must  be  a  major  objective  of  DSS  research. 

The  intuitive  notion  of  computer-based  decision  support  is  that  of  an 
information-processing  assistant,  a  cognitive  or  organizational  aid.  From  this  perspective, 
the  role  of  a  DSS  is  seen  as  augmenting  a  human  decision  maker's  limited 
information-processing  capabilities.  Such  a  view  leads  to  descriptive  mechanisms  focusing 
on  the  added  information-processing  functionality  that  a  system  makes  available  to  decision 
makers. 

This  intuitive  notion,  however,  is  not  complete.  DSS  must  be  recognized  as  not 
merely  augmenting  the  decisional  machinery  but  as  intervening  in  the  decision-making 
process.  The  introduction  of  a  DSS  into  a  decision-making  environment  changes  the  set 
and  sequence  of  information-processing  activities  performed  enroute  to  arriving  at  a 
decision.  A  good  descriptive  mechanism,  therefore,  must  pay  special  attention  to  those 
features  of  DSS  that  affect  the  way  in  which  decisions  are  reached.  While  the  proposed 
approach  to  DSS  description  satisfies  all  of  the  objectives  just  enumerated,  special  emphasis 
is  placed  on  comprehending  the  relationship  between  the  E>ecision  Support  System  and  the 
decision-making  process. 

2.  A  Three-Tiered  Approach 

Any  simple  descriptive  schema  for  DSS  will  not  easily  satisfy  the  multiple  objectives 
just  set  forth.  It  is  equally  undesirable  to  try  to  cover  the  various  objectives  with  a  set  of 
several  independent  descriptive  mechanisms.  Consequently,  the  approach  taken  here  is  to 
consider  a  sequence  of  three  levels  of  description,  with  each  tier  building  on  the 
descriptions  generated  by  the  previous  levels  of  analysis. 

The  three  analytic  tiers — based  on  Silver  (1986)  and  shown  schematically  in 


Figure  3--describe  a  Decision  Support  System  in  terms  of 


1)  its  functional  capabilities, 

2)  its  configuration  as  viewed  by  its  users,  and 

3)  its  attributes  as  a  "whole*  system. 

These  tiers  correspond  to  three  questions  commonly  asked  by  DSS  users; 

1)  "What  can  it  do?" 

2)  "What  does  it  look  like?" 

3)  "How  will  it  affect  my  decision  making?" 


Figure  3 

A  Three-Tiered  Schema  for  Describing  DSS 


Third:  |  System  Attributes 


II  II 

II  II 


Second:  |  User  View  of  Components  | 


II  11 

II  II 


First:  |  Functional  Capabilities  | 


Increasing 
Attention  to 
Entire  DSS  and 
to  Decision- 
Making  Processes 


As  we  move  upward  from  the  first  through  the  third  tier,  two  shifts  of  perspective 
become  apparent.  First,  the  descriptions  pay  increasing  attention  to  decision-making 
processes  and  to  the  perspective  of  DSS  as  process  interventions.  Second,  the  descriptions 
take  more  and  more  of  a  holistic  outlook  rather  than  focusing  on  the  individual  system 
components  in  isolation  from  one  another.  As  a  result,  the  uppermost  tier  plays  a  central 
and  innovative  role  in  achieving  the  descriptive  objectives. 
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3.  Ih£  Eirsi  Ikr  Functional  Canabilitlci 

The  most  basic— and  most  commonplace- -way  of  describing  a  Decision  Support 
System  is  in  terms  of  what  it  does.  This  first  descriptive  level  addresses  the  intuitive 
notion  of  DSS  as  information-processing  assistant,  identifying  the  information-processing 
capabilities  that  a  particular  DSS  offers  its  users.  ^Solves  linear  programs,”  "solves  the 
product- mix  linear  program,"  "allows  ad  hoc  queries  of  historical  sales  data,”  "graphs 
inventory  levels  over  time,"  "forecasts  income  and  expense,"  and  "performs  multi-attribute 
utility  calculations"  are  all  examples  of  functional  descriptions  of  DSS  capabilities. 

While  some  DSS  perform  a  single  function,  most  DSS  will  include  a  number  of 
different  information-processing  capabilities.  A  functional  description  of  these  systems 
could  be  as  simple  as  the  "laundry  list"  of  functions— that  is,  information-processing 
capabilities'-commonly  used  by  software  salesmen  and  DSS  developers  to  promote  their 
products.  Indeed,  such  lists  could  also  serve  as  the  basis  to  compare  different  DSS.  In 
order  to  truly  understand  the  role  of  a  DSS  in  supporting  managerial  decision  making, 
however,  we  desire  a  more  informative  means  of  describing  a  system’s  capabilities.  We 
need  a  mechanism  that  sheds  light  on  which  information-processing  functions  are 
appropriate  in  a  given  situation,  as  well  as  one  that  facilitates  compating  capabilities  across 
systems.  In  short,  we  need  a  consistent  means  to  classify  functions. 

An  early  classification  effort  was  Alter’s  (1980)  seven-category  taxonomy,  based  on 
the  "degree  of  action  implication  of  system  outputs."  Alter’s  work  was  a  classification 
scheme  for  the  DSS  of  its  day,  but  today  its  categories  apply  better  to  individual  functions 
within  a  single  system.  The  scheme  has  greater  historical  significance  than  ongoing 
importance,  however,  and  is  not  sufficiently  detailed  for  our  present  purposes. 

The  functional  capabilities  of  a  DSS  are  generally  intended  to  be  responsive  to  the 
decision-making  needs  of  its  users.  Indeed,  decisional  needs  are  the  chief  inputs  to  the 
analysis  and  design  process  that  produces  DSS.  What  better  way  to  classify  support 
functions,  then,  than  by  associating  them  with  the  managerial  needs  they  meet? 
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Fuller  exploration  of  alternatives,  earlier  detection  of  problems,  and  coping  with 
multiple  or  undefined  objectives  are  but  a  few  of  the  needs  commonly  felt  by  decision 
makers.  Each  of  these  represents  an  obstacle  to  reaching  a  decision,  an  element  of 
problem-solving  activity  that,  when  present,  makes  decision  making  difficult.  The 
difficulties  that  humans  and  organizations  encounter  in  making  decisions,  in  turn,  create  the 
potential  for  computer-based  support  systems  to  be  of  value.  To  understand  the  functional 
capabilities  of  a  DSS,  therefore,  is  to  comprehend  if  and  how  the  functionality  helps 
managers  satisfy  these  and  other  decisional  requirements. 

Identifying  the  needs  associated  with  particular  DSS  functions  should  be  a  natural 
process  for  both  DSS  researchers  and  practitioners.  Nonetheless,  it  is  easy  to  become 
preoccupied  with  analyzing  DSS  capabilities  in  terms  of  their  information-processing 
functions  rather  than  with  respect  to  their  decisional  roles.  "Graphs  data,"  "queries 
databases,"  and  "solves  optimization  models"  are  all  perfectly  good  descriptions  of  what  a 
system  docs,  but  they  do  not  convey  why  the  system  does  what  it  does.  The  phrases  do 
not  inform  us  why  it  matters  to  a  decision  maker  whether  these  functions  are  or  are  not 
included  in  the  system.  The  phrases  do  not  capture  the  effect  these  functions  can  have  on 
the  way  in  which  decisions  are  reached. 

Augmenting  simple  descriptions  of  functions  with  analyses  of  the  decisional  needs 
they  meet  would  be  most  valuable.  For  instance,  if  the  functional  capability  being 
described  is  "graphs  data,"  does  the  system  graph  historical  data  for  the  purpose  of 
detecting  problems,  or  does  it  graph  projected  data  for  the  purpose  of  exploring  alternative 
courses  of  action?  These  are  the  kinds  of  questions  that  a  functional  description  must 
answer  if  it  is  to  help  us  understand  the  role  of  the  DSS  in  supporting  problem  solving. 

Decision-making  needs  can  be  expressed  in  more  or  less  general  terms.  Each  of  the 


needs  mentioned  previously- -exploration  of  alternatives,  earlier  detection  of  problems,  and 
coping  with  multiple  or  undefined  objectives- -applies  to  a  broad  range  of  situations 
because  it  is  expressed  very  generally.  On  the  other  hand,  "solving  my  inventory  problem,' 
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"determining  the  profitability  of  my  loans,"  and  "setting  the  price  for  my  product,"  are 
much  more  specific  descriptions  of  decision  makers'  needs.  These  more  specific  needs 
correspond  very  closely  to  statements  of  the  decision  problems  themselves,  whereas  the  less 
specific  needs  reflect  general  characteristics  of  human  and  organizational  problem  solving. 

Why  speak  in  general  terms  at  all  when  we  can  study  more  specific  decision-making 
needs?  First,  the  functionality  of  some  DSS  can  only  be  described  in  general  terms.  Many 
systems  today  are  intended  to  be  broadly  applicable,  requiring  customization  before  being 
applied  to  particular  decision-making  situations.  Electronic  spreadsheets  offer  a  good 
example;  they  are  "content  free"  entities,  waiting  for  a  user  to  imbue  them  with 
problem-specific  content.  The  decisional  needs  met  by  such  systems  can  only  be  described 
in  the  more  general  terms. 

Second,  general  decision-making  needs  serve  to  classify  more  specific  decision-making 
needs.  In  fact,  decision-making  needs  can  be  organized  in  a  hierarchy,  with  needs  at  one 
level  refined  into  more  specific  needs  at  the  next  level  (see  Figure  4).  Special  leaf  nodes 
representing  information-processing  functions  can  then  be  attached  to  those  nodes  whose 
needs  they  satisfy.  Moreover,  such  leaf  nodes  could  be  placed  at  any  level  of  the 
hierarchy,  depending  on  the  degree  of  specificity  of  the  needs  they  meet.  A  small  portion 
of  an  abstract  needs/functions  hierarchy  is  illustrated  in  Figure  4,  where  circular  nodes 
correspond  to  decision-making  needs  and  rectangular  nodes  represent  information-processing 
capabilities.  We  see  that  decision-making  needs  can  be  used  as  a  multi-level  classification 
scheme  for  DSS  functionality. 

DSS  researchers  can  proceed  in  two  directions  along  the  path  of  inquiry.  They  can 
begin  with  functional  capabilities  found  currently  in  Decision  Support  Systems  and  attempt 
to  define  which  decision-making  needs  those  capabilities  meet  and  how  they  do  so. 
Alternatively,  researchers  can  choose  a  decision-making  need--at  any  level  of 
specificity- -and  propose  functional  capabilities  that  can  satisfy  it.  Either  approach  should 
prove  fruitful  in  developing  the  tree  of  decision-making  needs  and  information-processing 


Figure  4 


Explanation.  Information-Processing  Function  A  meets  the 
General  Decision-Making  Need. 

Information-Processing  Functions  B  and  C  meet 
Specific  Need  1. 

Information-Processing  Function  D  meets 
Specific  Need  2. 
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functions.  The  more  expansive  the  tree,  the  greater  our  understanding  of  the  role  of 
information-processing  technology  in  supporting  managerial  activity. 

Summary.  The  first-tier  description  of  DSS  is  the  one  most  commonly  found  in 
practice  today.  It  is  the  sine  qua  non  of  descriptions,  for  without  an  understanding  of  a 
system’s  functional  capabilities,  we  can  say  very  little  about  that  system.  Augmenting 
simple  descriptions  of  information-processing  activities  with  analyses  of  the  decisional  needs 
met  by  each  function  can  increase  significantly  the  value  of  this  first-tier  description.  The 
information  provided  by  the  first-tier  analysis  serves  as  the  basis  for  descriptions  at  the 
upper  two  levels. 

4.  Ih£  Second  ligi:  User  View  &£  System  Components 

Beyond  what  it  can  do,  an  important  aspect  of  a  DSS  is  how  it  is  organized.  A 
system’s  configuration  can  be  seen  from  two  different  perspectives;  the  internal  view  and 
the  external  view.  The  internal  view  describes  the  architecture  of  a  system’s  underlying 
technological  building  blocks--in  terms  of  Sprague’s  (1980)  framework,  the  database,  dialog, 
and  model  base  management  components.  The  external  view  describes  how  a  system’s 
functional  capabilities  are  packaged --that  is,  how  the  system  components  appear  to  users. 

It  is  the  user  perspective  that  is  important  for  our  present  descriptive  purposes,  and  this 
view  constitutes  the  second  tier  of  analysis. 

A  given  set  of  functional  capabilities  can  be  packaged  for  users  in  a  number  of 
ways.  For  instance,  consider  the  following  questions  that  can  be  asked  about  a  system’s 
(external)  configuration.  Do  users  see  discrete  operations  that  can  be  invoked  in  any  order, 
or  do  they  encounter  a  sequence  of  steps  organized  in  a  predetermined  fashion?  Do  users 
see  a  modeling  capability  independent  of  individual  models,  or  do  they  access  a  set  of 
fully-packaged  models?  Do  users  employ  database  and  graphics  capabilities  that  exist 
independently  of  particular  datasets,  or  do  they  see  a  package  of  particular  databases  and 
retrieval  capabilities?  Can  users  modify  the  system’s  operators,  data,  models,  and 
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representations?  These  and  similar  questions  are  answered  by  the  second  level  of  analysis. 

The  second  tier  clearly  builds  on  the  information  provided  by  the  first-tier  analysis. 
Since  the  same  basic  information-processing  functions  can  be  packaged  in  a  variety  of 
different  ways,  however,  the  user  view  represents  a  significant  level  of  analysis  in  its  own 
right.  The  way  in  which  a  system’s  components  appear  to  its  users  can  play  a  determining 
role  in  how  that  system  is  used,  hence,  how  it  affects  decision-making  behavior. 

In  order  to  satisfy  the  objective  of  being  able  to  describe  as  well  as  differentiate 
DSS,  it  is  desirable  to  define  a  vocabulary  that  can  be  applied  to  describing  the  user  view 
of  any  DSS.  We  may  think  of  such  a  schema  as  a  "generic  user  view." 

The  generic  user  view  most  widely  cited  in  the  literature  is  the  ROMC  approach 
(Carlson,  1983;  Sprague  and  Carlson,  1982),  which  identifies  four  DSS  components: 
representations,  operations,  memory  aids,  and  control  devices.  Representations  are  visual 
images  corresponding  to  conceptualizations  of  information  such  as  tables,  lists,  graphs,  and 
maps.  Operations  are  the  devices  invoked  by  users  to  perform  information-processing 
activities  and  may  be  simple  manipulations  or  may  involve  complicated  decision  aids  such 
as  simulation  models  or  forecasting  models.  Memory  aids  support  the  use  of 
representations  and  operations  by  storing  and  retrieving  information  in  a  variety  of 
manners,  and  control  mechanisms  assist  the  user  in  directing  the  use  of  the  DSS.  ROMC's 
proponents  assert  that  one  of  its  chief  advantages  is  allowing  users  to  structure  their  own 
decision-making  processes- -through  the  selection  of  operations- -as  opposed  to  locking  users 
into  a  predefined  sequence  of  steps. 

While  the  ROMC  approach  is  quite  popular  and  has  a  number  of  appealing 
characteristics,  it  has  two  drawbacks  as  a  generic  user  view  when  we  wish  to  analyze  DSS 
in  terms  of  their  effects  on  decision-making  processes.  First,  although  ROMC 
accommodates  very  well  those  systems  that  give  users  free  reign  in  choosing  operations,  it 
cannot  be  used  to  describe  systems  that  deliberately  limit  user  discretion  in  defining 
decision-making  processes.  Second,  ROMC  does  not  emphasize  those  DSS  components  that 
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are  most  important  for  understanding  how  a  system  affects  its  users'  decision-making 
processes. 

The  new  generic  user  view  proposed  here— discussed  in  greater  detail  by  Silver 
(1986)— also  consists  of  four  types  of  principal  components: 

•  Operators, 

‘  Navigational  Aids, 

'  Adaptors,  and 

*  Sequencing  Rules. 

Figure  3  provides  a  schematic  illustration  of  this  generic  user  view  of  DSS,  including  these 
principal  components  together  with  their  inputs  and  outputs. 

Operators.  The  workhorses  of  a  Decision  Support  System  are  its  operators,  the 
devices  invoked  by  users  to  access  the  functional  capabilities.  Commands  typically  found 
in  DSS--for  example,  "List,"  "Query,"  "Calculate,"  "Regress,"  and  "Optimize"- -are  all 
operators.  Operators  are  comparable  to  ROMC’s  operations.  Operators  are  the  dominant 
component  here,  however,  whereas  in  ROMC,  representations  dominate.  Since  operators 
control  a  system’s  information-processing  activities,  they  are  central  to  describing  how  a 
system  affects  decision  making. 

When  an  operator  requires  data  or  models  as  inputs,  two  configurations  are  possible. 
Data  or  models  can  be  embedded  in  the  operator  so  that  users  see  a  single,  non-separable 
entity  and  cannot  manipulate  the  data  or  models  independently  of  the  operator. 
Alternatively,  data  or  models  can  be  treated  as  entities  separate  from  the  operator,  in 
which  case  users  must  specify  the  data  and  models  to  be  used  at  the  time  an  operator  is 
invoked.  The  alternative  configurations  present  a  trade-off  between  the  ease  of  use  and 
the  flexibility  afforded  to  users.  The  relative  merits  of  each  approach  require  study. 

As  an  example,  consider  the  production-mix  problem.  An  operator  could  be  defined 
in  at  least  three  different  ways:  to  solve  a  particular  production-mix  problem,  to  solve  the 


generalized  production-mix  problem  with  users  supplying  the  problem-specific  data,  or  to 
solve  any  linear  program  with  users  supplying  the  data  as  well  as  the  production-mix 
model.  The  first  case  embeds  data  and  models  within  the  operator,  the  third  case  separates 
both  data  and  models  from  the  operators,  and  the  middle  case  falls  in  between,  embedding 
the  model  but  leaving  the  data  separate. 

Navigational  Aids.  Navigational  aids  assist  users  in  steering  through  a  system  and 
its  operators.  When  using  complex  DSS  that  offer  many  operators  from  which  to  choose, 
simply  deciding  what  to  do  next  may  itself  be  a  formidable  task.  Decision  makers  may 
need  to  choose  among  competing  operators — for  example,  implementations  of  different 
choice  rules- -any  one  of  which  is  adequate  to  perform  a  particular  task.  Similarly,  users 
may  be  uncertain  as  to  which  models,  data,  or  representations  to  employ  as  inputs  to  the 
operators  they  select.  Alternatively,  decision  makers  may  know  which  operators  and  inputs 
they  intend  to  use,  but  be  uncertain  as  to  the  order  in  which  to  use  them.  Navigational 
aids  that  either  offer  helpful  information  or  suggest  possible  paths  through  the  system  can 
therefore  play  critical  roles  in  determining  how  a  DSS  is  used  and,  ultimately,  how 
decisions  are  made. 

Context-sensitive  help  messages  and  look-ahead  menus  are  simple  aids  commonly 
found  in  systems  today.  Help  messages  designed  specifically  for  a  user’s  current  location 
within  the  system  can  provide  information  useful  in  choosing  what  course  to  follow  next. 
Similarly,  menus  providing  a  view  of  the  operators  available  one  step  beyond  the  current 
position  also  assist  users  in  planning  ahead  and  structuring  their  use  of  the  system. 

Navigational  aids  come  in  a  variety  of  forms  and  can  be  far  more  complex  than  these 
simple  examples.  Some  navigators  provide  users  with  suggested  courses  of  action  while 
others  only  offer  pertinent  information  concerning  possible  actions.  Some  navigators  are 
short  range,  helping  only  with  choosing  the  next  step,  while  others  are  more  long  range, 
helping  define  a  longer  sequence  of  activities.  Some  navigational  aids  interact  heavily  with 
users,  while  others  generate  their  information  and  suggestions  without  user  involvement.  No 
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matter  what  their  form,  by  influencing  the  selection  and  use  of  operators,  navigational  aids 
can  play  critical  roles  in  determining  users*  decision-making  processes. 

Navigational  aids  present  a  combination  of  technological  and  behavioral  issues  for  DSS 
researchers.  The  technological  challenge  is  to  invent  more  sophisticated  and  more 
supportive  navigational  aids  than  are  prevalent  in  DSS  today.  The  related  behavioral 
question  is  how  such  aids  will  affect  users*  decision-making  processes. 

Adaptors.  An  important  concept  in  the  literature  is  the  notion  that  DSS  must  be 
"adaptive"  in  order  to  support  the  personal  styles  of  individual  decision  makers  and/or  to 
respond  to  changes  in  decision-making  environments  over  time  (Keen,  1980).  The  degree 
of  customizability  or  adaptivity  of  a  Decision  Support  System  is  a  function  of  the  power  of 
its  "adaptors,"  devices  invoked  by  the  user  to  modify  existing  operators  and  navigational 
aids  or  to  create  new  ones.  For  example,  if  a  system  includes  an  operator  that  measures 
angles  in  degrees,  a  user  might  employ  an  adaptor  to  modify  it  to  use  radians.  If  a  DSS 
includes  matrix  algebra  functions  but  does  not  include  a  regression  operator,  a  user  could 
employ  an  adaptor  to  create  the  regression  operator  from  the  matrix  algebra  functions. 

DSS  vary  widely  in  terms  of  the  presence,  nature,  and  power  of  their  adaptors. 

Sequencing  Rules.  Operators,  navigational  aids,  and  adaptors  are  all  invoked  by  the 
user.  In  contrast,  sequencing  rules  govern  the  operation  of  a  DSS  by  the  user,  determining 
which  of  the  operators,  navigational  aids,  and  adaptors- -users  are  allowed  to  invoke  at  any 
point  during  a  session.  More  generally,  the  sequencing  rules  determine  which  sequences  of 
invoked  devices  are  legitimate  and  which  are  not  permitted. 

The  set  of  ail  Decision  Support  Systems  can  be  partitioned  into  two  classes  based  on 
the  types  of  sequencing  rules  they  enforce.  If  a  DSS  has  a  "trivial  rule  set,"  then  it  does 
not  impose  any  restrictions  on  the  sequence  of  operators,  adaptors,  and  navigators  invoked 
by  users.  Any  of  these  devices  is  available  for  use  at  any  point  in  time.  If,  however,  a 
system  uses  a  "non-trivial  rule  set,"  then  it  limits  the  sequence  of  activities  in  one  or  more 


ways.  In  this  case,  different  sets  of  operators,  adaptors,  and  navigators  are  legitimate  for 
use  at  different  points  in  time. 

Non-trivial  rules  can  limit  users  in  a  number  of  different  ways.  Some  rules  may 
limit  what  can  be  done  next  based  only  on  what  the  user  did  last,  whereas  others  may 
consider  the  entire  sequence  of  previous  activities.  Some  rules  may  depend  only  on  the 
identity  of  operators  invoked  previously,  while  others  may  also  depend  on  the  results  they 
returned.  Some  rules  may  constrain  only  which  operators  can  be  used  next,  whereas  others 
may  constrain  the  inputs  as  well. 

A  variety  of  purposes  can  be  served  by  employing  non-trivial  rule  sets  to  constrain 
decision-making  processes.  For  instance,  a  sequencing  rule  might  require  projected  budgets 
showing  deficits  to  be  balanced  before  a  user  can  invoke  any  other  operators.  Similarly,  a 
rule  might  require  users  to  examine  sensitivity  information  after  running  linear  programs 
whose  results  are  not  very  robust.  Clearly,  the  set  of  sequencing  rules  can  play  a  major 
role  in  determining  the  effect  a  DSS  has  on  decision-making  processes. 

It  is  the  concept  of  sequencing  rules  that  allows  this  generic  user  view  to  handle 
systems  that  are  not  describable  by  ROMC.  ROMC,  by  intention,  describes  only  those  DSS 
with  trivial  rule  sets.  There  is  no  ROMC  mechanism  for  capturing  the  role  of  non-trivial 
sequencing  rules  in  a  DSS. 

Sequencing  rules  raise  research  questions  similar  to  those  of  navigational  aids.  On  the 
one  hand,  there  is  the  technological  concern  of  how  to  build  systems  with  complex, 
non-trivial  rule  sets.  The  technology  is  only  useful,  however,  if  we  also  have  a  handle 
conceptually  on  the  types  of  information-processing  and  decision-making  constraints  those 
sequencing  rules  should  implement. 

Summary.  The  second-tier  analysis  builds  on  the  previous  level's  description  of 
functional  capabilities  to  capture  how  a  Decision  Support  System’s  components  appear  to  its 
users.  This  level  of  analysis  corresponds  to  an  important  set  of  alternative  configurations 
for  packaging  a  system’s  functional  capabilities.  To  facilitate  describing  and  differentiating 
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DSS  at  this  analytic  level,  a  generic  user  view  is  a  valuable  mechanism.  The  generic  user 
view  proposed  here- -consisting  of  operators,  navigational  aids,  adaptors,  and  sequencing 
rules- -contrasts  with  the  popular  ROMC  approach  by  emphasizing  those  system  components 
that  play  a  determining  role  in  the  effect  a  DSS  has  on  decision-making  processes. 

5.  Ili£  Third  Ucc:  System  Attributes 

When  we  view  DSS  as  interventions  into  decision-making  processes,  we  are  more 
concerned  with  the  questions  "How  is  the  DSS  likely  to  affect  the  user’s  behavior?”  and 
"What  is  the  user  likely  to  do  with  the  system?”  than  we  are  with  the  questions  "What  can 
the  system  do?"  and  "What  does  the  system  look  like?"  We  shift  our  attention  from  the 
system  to  the  decision  maker,  considering  how  users  can  and  will  integrate  the  DSS  into 
their  decision-making  processes.  In  so  doing,  we  move  beyond  considering  individual 
functional  capabilities  and  how  they  are  configured  to  studying  attributes  of  the  system  as 
a  whole.  These  system  attributes  constitute  the  third  descriptive  tier. 

The  third  tier  builds  on  information  provided  by  the  lower  two  descriptive  levels  tc 
analyze  how  the  parts  of  a  DSS  fit  together  synergistically  to  form  a  whole  whose  effects 
on  decision  making  can  be  different  from  the  sum  of  those  of  its  parts.  The  attributes 
represent  collective  statements  about  the  components  of  a  DSS  and  the  relationships  among 
them.  For  instance,  attributes  indicate  whether  a  system’s  information-processing  functions 
complement  one  another,  substitute  for  one  another,  or  are  unrelated  to  one  another. 
Attributes  capture  if  and  how  a  DSS  allows  users  to  combine  individual  capabilities. 
Attributes  also  identify  whether  the  whole  decision-making  process  or  only  a  portion 
thereof  is  supported. 

Three  such  system  attributes  (Silver,  1986)  are  defined  and  discussed  here: 

•  System  Restrictiveness, 

'  System  Guidance,  and 


System  Focus. 
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Sv«teni  RgitricHvcnen:  the  degree  to  which  and  the  manner  in  which  a 
Decision  Support  System  restricts  its  users’  decision-making  processes  to 
a  particular  subset  of  all  possible  processes. 

Decision  Support  Systems  are  usually  viewed  intuitively  as  augmenting  decision 
makers’  capabilities,  not  as  limiting  their  decision-making  processes.  This  position  must  be 
modified,  however,  by  recognizing  that  a  DSS  actually  intervenes  in  the  processes  through 
which  decisions  are  made.  To  the  extent  that  decision  makers  rely  on  DSS  in  solving  their 
problems,  the  specifications  of  these  systems  can,  in  fact,  be  a  limiting  set  of  features. 

DSS  are  frequently  implemented  in  situations  where  unique,  well-defined 
decision-making  processes  do  not  exist.  In  these  cases,  either  there  is  no  well-defined 
method  for  solving  the  problem  or  there  are  multiple,  competing  solution  techniques. 
One-time  decisions,  such  as  deciding  where  to  locate  a  nuclear  power  plant,  illustrate  the 
former  case.  The  many  competing  multi-criteria  decision  making  techniques  proposed  by 
operations  researchers  and  the  various  alternative  descriptive  models  of  individual  choice 
studied  by  behavioral  decision  theorists  offer  examples  of  the  latter  case. 

In  situations  such  as  these,  where  defining  an  appropriate  decision-making  process  is 
itself  a  major  concern,  which  features  are  included  in  a  DSS  and  which  are  excluded  play 
a  critical  role  in  determining  the  process  that  is  ultimately  followed.  Nonetheless,  when 
analyzing  Decision  Support  Systems,  we  tend  to  focus  only  on  the  question  "What  features 
are  to  be  built  into  the  system?"  and  disregard  the  question  of  "What  features  are  not  to  be 
included?"  If  our  purpose  is  simply  to  describe  what  the  system  can  do,  then  answering 
only  the  first  question  may  be  adequate.  If  we  wish  to  understand  how  the  system  affects 
decision-making  processes,  however,  both  questions  are  equally  important.  For  instance,  if 
a  DSS  supports  many  processes  but  does  not  support  the  current  decision-making  process, 
then  recognizing  what  has  been  excluded  from  the  system  is  surely  as  crucial  to  the 
analysis  as  knowing  what  has  been  included. 

DSS  vary  significantly  in  terms  of  how  restrictive  they  are  and  how  they  are 
restrictive.  In  general,  since  decision-making  processes  are  sequences  of 


information-processing  activities,  DSS  restrict  processes  by  limiting  the  set  of 
information-processing  sequences  users  can  perform.  The  generic  user  view  proposed 
earlier  provides  a  language  for  describing  more  specifically  the  various  ways  that  the 
features  of  DSS  can  be  restrictive. 

First  and  foremost,  the  set  of  operators  can  be  restricted.  For  instance,  to  cause 
decision  makers  to  use  the  'elimination  by  aspects*  (Tversky,  1972)  heuristic  rather  than 
"multi-attribute  utility*  models,  operators  supporting  the  former  approach  are  included  while 
those  necessary  for  the  latter  technique  are  excluded.  Second,  for  those  operators  included 
in  the  DSS,  the  Inputs- -especially  data  and  model  parameters- -can  be  limited.  For 
example,  regression  analysis  might  be  included  in  a  DSS  but  certain  datasets  might  not  be 
permitted  as  inputs  to  the  regression  operators.  Third,  the  system  can  employ  non -trivial 
sequencing  rules  to  constrain  the  order  in  which  operators  can  be  used.  For  instance,  a 
sequencing  rule  might  require  that  when  Durbin-Watson  statistics  show  autocorrelation,  data 
must  be  transformed  before  running  regressions.  Finally,  the  ability  of  users  to  modify 
and  or  expand  the  set  of  operators  can  be  limited  by  restricting  the  system’s  adaptors. 

While  more  research  is  required  to  make  prescriptive  claims  concerning  how  much 
and  what  form  of  restrictiveness  is  appropriate  in  a  given  situation,  one  can  identify  a 
number  of  factors  favoring  greater  or  lesser  amounts  of  restrictiveness.  Two  important 
factors  that  often  favor  increased  restrictiveness  for  a  DSS  are  a  need  to  prescribe  a 
particular  approach  to  decision  making  and  a  need  to  proscribe  a  particular  problem-solving 
approach.  That  is,  a  system  can  be  designed  to  impose  a  normative  approach  to  decision 
making,  on  the  one  hand,  or  a  system  can  be  constructed  to  prevent  decision  makers  from 
using  some  undesirable  approach,  on  the  other  hand.  A  third  factor  favoring  more 
restrictive  DSS  is  a  concern  not  to  overload  and  overwhelm  decision  makers  with  large  sets 
of  capabilities;  limiting  the  available  techniques  can  promote  structure  in  decision-making 
processes. 

The  factors  favoring  restrictiveness  are  weighed  against  a  set  of  factors  opposing 
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restrictiveness.  The  desire  to  foster  greater  flexibility  leading  to  enhanced  creativity  and 
exploratory  learning--two  often-cited  DSS  objectives- -suggests  building  a  DSS  that  is  less 
restrictive.  So,  too,  does  the  intention  to  intplement  a  system  than  can  be  applied  easily  to 
new  and  or  changing  decision-making  environments.  The  most  important  reason  for 
making  a  DSS  less  restrictive,  however,  is  that  excessive  restrictiveness  may  prevent  use.  If 
decision  makers  feel  uncomfortably  restricted  by  a  system,  they  may  choose  not  to  use  it. 
No  matter  how  compelling  the  reasons  are  for  restricting,  a  system  will  not  accomplish  its 
objectives  if  it  is  never  used. 

System  Guidance;  The  degree  to  which  and  the  manner  In  which  a 
Decision  Support  System  guides  its  users  in  constructing  and  executing 
decision-making  processes,  by  assisting  them  in  choosing  and  using  Its 
operators. 

Providing  decision  makers  with  flexibility  in  the  use  of  their  Decision  Support 
Systems  is  often  claimed  to  be  an  important  element  of  DSS  design.  When  a  significant 
amount  of  flexibility  is  offered  by  a  DSS,  however,  mechanisms  may  be  required  for 
helping  decision  makers  take  advantage  of--read,  cope  with--the  discretionary  power  they 
have  been  given  in  controlling  the  operation  of  the  system. 

Any  computer-based  system  that  allows  its  users  to  choose  among  different  operators, 
datasets,  or  models  must  provide  them  with  some  means  of  communicating  their  selections. 
Menus  and  command  interpreten  represent  typical  devices  for  accomplishing  this  task. 

When  an  interactive  system  contains  numerous  operators,  datasets,  or  models,  it  may  be 
desirable  to  augment  these  technologically-necessary  selection  devices  with  facilities  for 
helping  users  determine  what  to  do  next.  Context  sensitive  help  messages,  for  example, 
have  become  commonplace  means  of  assisting  users  to  navigate  through  complex  systems. 

The  need  for  assistance  is  particularly  great  in  systems  supporting  decision  making. 
Often  the  ”meta-choice”  decision  of  "deciding  how  to  decide"  is  the  most  difficult  part  of 
solving  a  problem,  as  decision  makers  may  confront  many  tough  questions  in  selecting 
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appropriate  solution  procedures  for  their  problems.  For  instance,  given  a  particular 
multi-attribute  problem,  should  a  process  method  or  a  scoring  method  be  used  to  choose 
among  alternatives?  Should  a  compensatory  or  non-compensatory  rule  be  used?  Should  a 
serial  approach  be  used  where  solutions  are  generated  and  evaluated  one  at  a  time,  or 
should  a  parallel  process  be  employed  where  a  set  of  alternatives  is  generated  and  one 
course  of  action  is  then  selected  from  among  these  candidates? 

When  a  DSS  supports  many  different  solution  techniques  by  including  a  variety  of 
different  operators,  datasets,  and  models  it  may  also  provide  support  for  the  "meta-process" 
of  structuring  the  decision-making  process.  More  than  simply  helping  users  navigate 
through  complex  systems,  such  assistance  is  based  on  decision-making  considerations,  such 
as  those  just  enumerated  for  multi-attribute  problems.  In  particular,  such  guidance 
addresses  the  decisional  relationships  among  operators  such  as  which  operators  function  as 
substitutes  and  which  as  complements  within  coherent  decision-making  processes.  Such 
guidance  is  implemented--in  the  language  of  the  generic  user  view--through  navigational 
aids  in  the  DSS. 

Just  as  assistance  in  selecting  operators  and  structuring  decision-making  processes  can 
be  valuable,  so  too  can  computer-based  support  for  using  the  selected  operators  and 
executing  the  decision-making  processes.  The  conventional  wisdom  concerning  DSS  is  that 
they  combine  the  best  features  of  humans  and  machines.  According  to  this  view,  human 
decision  makers  typically  perform  the  judgmental  tasks,  while  the  machines  perform  other 
information-processing  activities.  Nonetheless,  human  decision  makers  can  benefit  from 
computer-based  assistance  at  those  points  in  the  decision-making  process  where  they  must 
execute  judgment. 

Consider,  for  example,  a  decision  maker  who  elects  to  employ  an  elimination  by 
aspects  approach  to  choosing  a  city  in  which  to  live.  A  simple  DSS  for  implementing  this 
choice  rule  might  allow  its  users  to  enter  attributes  and  acceptable  ranges  for  their  values, 
producing  a  list  of  those  cities  satisfying  the  specified  criteria.  While  such  a  system  does 
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aid  decision  makers  by  performing  the  necessary  database  searches,  it  does  not  assist  with 
the  critical  judgmental  tasks  of  choosing  and  ordering  attributes  and  defining  value  ranges. 
Another--perhaps  more  supportive- -system  might  provide  such  judgmental  assistance. 

The  need  for  navigating  through  a  complex  system,  the  need  for  structuring  a 
decision-making  process,  and  the  need  for  executing  judgment  all  provide  opportunities  for 
including  guidance  mechanisms  in  a  DSS.  DSS  will  vary  greatly  in  terms  of  the  extent  and 
nature  of  the  guidance  they  offer.  Since  the  guidance  a  system  provides  can  have  a  major 
impact  on  the  processes  through  which  decisions  are  made,  the  system  guidance  attribute 
plays  a  key  role  in  describing  and  differentiating  DSS  in  terms  of  their  effects  on  decision 
making. 

There  is  an  important  interaction  between  the  restrictiveness  and  guidance  attributes. 
The  more  restrictive  a  Decision  Support  System  is,  the  less  discretion  the  user  has,  hence 
the  less  room  exists  for  meaningful  guidance.  DSS  builders  wishing  to  influence  decisional 
behavior  therefore  confront  a  fundamental  design  decision:  whether  to  impose 
decision-making  processes  through  restrictiveness  or  to  propose  decision-making  processes 
through  guidance. 

System  Focus:  The  degree  to  which  and  the  manner  in  which  a 
Decision  Support  System’s  operators  provide  specialized  support  for 
decision-making  processes. 

An  important  property  of  a  Decision  Support  System  is  the  degree  to  which  it  is 
customized  for  the  particular  decision-making  environment(s)  it  supports.  To  a  large 
extent,  the  customization  of  a  DSS  is  determined  by  the  specialization  of  its  operators. 

The  focus  attribute  makes  a  collective  statement  about  the  degree  and  manner  of  decisional 
specialization  of  a  system's  operators. 

In  general,  an  operator’s  specialization  can  be  identified  simply  in  terms  of  its  inputs, 
its  outputs,  and  how  it  transforms  the  former  into  the  latter.  The  inputs  and  outputs 
define  what  the  operator  does  and  the  transformation  determines  how  it  does  it.  When 


studying  DSS  operators,  however,  more  needs  to  be  said.  Capturing  the  specialization  of 
an  operator  requires  describing  its  distinctiveness  not  in  the  language  of  computer  science 
or  mathematics  but  in  the  language  of  decision  making.  One  must  be  able  to  characterize 
the  ways  in  which  it  does  and  does  not  contribute  to  solving  decision-making  problems. 

Consider,  for  example,  a  pair  of  operators  implementing  multi-attribute  utility  theory 
and  elimination  by  aspects,  respectively.  Functionally,  both  take  a  set  of  alternatives  with 
associated  attribute  values  as  inputs  and  produce  a  single  alternative  as  an  output.  From  a 
decision-making  perspective,  however,  the  operators  would  be  described  as  implementations 
of  decision  rules  executed  during  the  "choice”  phase  of  a  decision-making  process. 

Moreover,  multi-attribute  utility  theory  would  be  characterized  as  a  compensatory  scoring 
method,  whereas  elimination  by  aspects  would  be  classified  as  a  non-compensatory  process 
method.  These  descriptions  offer  a  good  deal  of  information  concerning  the  role  the 
operators  play  within  decision-making  processes. 

The  general  wisdom  concerning  DSS  is  that  the  more  focused  or  specialized  an 
operator,  the  more  supportive  it  can  be  of  decision  makers.  Nonetheless,  DSS  vary  widely 
in  terms  of  how  focused  their  operators  are.  Any  given  DSS  is  itself  likely  to  have  a 
significant  mix  of  focused  and  unfocused  operators.  When  a  DSS  contains  a  preponderance 
of  focused  operators,  we  refer  to  the  system  as  a  whole  as  focused. 

Operators  can  be  focused  in  many  ways.  Any  concept  that  classifies  decision-making 
environments  or  partitions  decision-making  processes  can  serve  as  a  dimension  for  analyzing 
focus.  For  instance,  Huber  (1981)  has  suggested  that  different  decision  aids  are  appropriate 
for  different  organizational  decision-making  styles.  Such  specialized  aids  would  then  be 
focused  on  either  rational,  programmed,  political,  or  garbage  can  environments.  Similarly, 
operators  can  be  focused  on  particular  functional  areas,  such  as  Finance  or  Marketing. 

A  special  dimension  of  focus  is  the  phase  of  decision  making.  Using  Simon’s  (1960, 
1977)  "Intelligence,"  "Design,"  "Choice,"  and  "Review,"  model--or  any  of  the  other  stage 
models- -one  can  analyze  whether  or  not  a  system’s  operators  are  tailored  for  particular 


phases  of  the  decision-making  process.  If  so,  then  the  system  is  focused  with  respect  to 
phase.  An  important  question  to  ask  of  such  focused  systems  is  whether  or  not  they  are 
"complete."  That  is,  are  they  *soup-to-nuts*  DSS  with  at  least  one  operator  for  each  phase, 
or  are  they  fully  specialized  DSS,  with  all  operators  concentrating  on  a  single  phase. 

When  a  significant  proportion  of  a  DSS’s  operators  are  focused  with  respect  to  one  or 
more  dimensions,  it  becomes  possible  to  analyze  that  system  in  terms  of  the  relationships 
between  its  operators.  For  instance,  one  can  speak  of  operators  being  substitutes  for  one 
another,  complements  to  one  another,  or  unrelated  to  one  another.  Such  analyses  provide 
both  a  deeper  understanding  of  the  synergistic  nature  of  the  DSS  as  a  whole  and  greater 
insights  into  the  role  the  system  can  play  in  supporting  the  decision-making  processes  of 
its  users. 

Summary.  The  analysis  of  system  attributes  culminates  the  three-tiered  analysis, 
building  on  the  informational  content  of  the  first  two  tiers  to  characterize  how  a  Decision 
Support  System,  when  considered  as  a  "whole,"  is  likely  to  affect  the  decision-making 
processes  of  its  users.  This  uppermost  analytical  tier  concentrates  on  how  a  system  can  be 
used  by  decision  makers,  rather  than  on  what  a  system  can  do.  Each  of  the  three  system 
attributes  contributes  a  different  collective  statement  about  the  system’s  decisional  features. 
While  all  three  attributes  can  be  applied  to  any  DSS,  system  restrictiveness  and  system 
focus  are  the  most  relevant  for  analyzing  today’s  DSS,  since  most  systems  currently  in  place 
contain  relatively  little  of  the  "meta-support"  captured  by  the  system  guidance  attribute. 

6.  Research  Implications 

The  three-tiered  descriptive  schema  has  numerous  implications  for  continued  DSS 
research.  Some  of  the  research  issues  that  follow  consist  primarily  of  further  development 
of  the  schema,  while  others  represent  applications  of  the  schema  to  existing  DSS  research 
problems.  Naturally,  there  is  some  overlap  between  these  two  endeavors. 
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The  Three  Tlere.  Our  understanding  of  each  of  the  three  descriptive  tiers  can 
benefit  from  additional  research.  The  chief  research  activity  at  the  first  tier  is  matching 
information-processing  capabilities  with  decision  makers’  needs.  Such  research  can  lead 
both  to  a  better  understanding  of  how  existing  information-processing  capabilities  support 
managers  as  well  as  to  the  invention  of  new  and  more  supportive  capabilities. 

Research  at  the  second  level  tends  to  integrate  technological  and  behavioral  issues. 

The  challenge  is  to  devise  and  implement  new  DSS  components- -for  instance,  new  types  of 

navigational  aids  or  new  forms  of  sequencing  rules— that  accomplish  particular  objectives  in 

terms  of  their  effects  on  the  problem-solving  behavior  of  their  users.  Another  research 
topic  at  this  level  is  to  understand  better  the  trade-offs  among  alternative  configurations  of 
components.  For  example,  what  are  the  relative  merits  of  embedding  data  and  models  in 
operators  versus  keeping  them  as  separate  entities? 

Each  of  the  three  system  attributes— restrictiveness,  guidance,  and  focus- -can  serve  as 
the  basis  for  further  descriptive,  prescriptive,  and  technological  research.  The  purpose  of 
additional  descriptive  studies  is  to  understand  better  the  effects  that  the  attribute  has  on 

decision-making  behavior.  For  instance,  how  much  and  what  forms  of  restrictiveness  tend 

to  inhibit  system  use?  Similarly,  what  forms  of  guidance  are  most  likely  to  influence 
decision  makers  and  how?  Based  upon  the  results  of  the  descriptive  studies,  the  next  set 
of  issues  are  prescriptive.  Once  we  understand  how  the  attributes  affect  decisional 
performance,  we  can  prescribe  the  forms  of  restrictiveness,  guidance,  and  focus  that  are 
appropriate  in  a  given  situation.  Finally,  technological  questions  still  remain  concerning 
how  to  implement  DSS  possessing  the  desired  restrictiveness,  guidance,  and  focus. 

The  DSS  gg  a  Research  Variable.  Recalling  Figure  2  and  the  various  research 
questions  it  suggested,  notice  the  pivotal  role  played  by  the  Decision  Support  System.  The 
DSS  serves  both  as  the  output  of  the  systems  analysis  and  design  process  and  as  an  input 
to  the  process  of  system  use.  In  a  large  number  of  DSS  research  studies,  therefore,  the 
key  variable  is  the  DSS  itself. 
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Sometimes,  the  DSS  is  the  dependent  variable,  as  in  the  question  *Do  different 
analysis  and  development  processes  systematically  produce  different  types  of  DSS?"  Other 
times,  the  DSS  is  the  independent  variable,  such  as  when  we  ask,  "Are  some  types  of  DSS 
more  likely  to  be  used  than  others?"  In  the  former  case,  it  is  important  for  us  to  examine 
a  collection  of  DSS  and  describe  systematically  how  they  differ  from  one  another.  In  the 
latter  situation,  we  need  to  be  able  to  vary  the  features  of  DSS  systematically. 

The  descriptive  approach  proposed  here  gives  researchers  both  of  these  analytic 
capabilities.  Moreover,  the  three  separate  tiers  can  help  to  isolate  particular  phenomena  of 
interest.  For  example,  the  functional  capabilities  can  be  held  constant  (first  tier),  while 
their  packaging  (second  tier)  is  varied.  The  three-tiered  mechanism  should  therefore  serve 
as  a  foundation  for  studying  many  of  the  contingencies  associated  with  DSS  development 
and  use. 

Perhaps  the  most  fundamental  of  all  DSS  research  questions  is  "How  do  DSS  affect 
the  decision-making  behavior  of  their  users?"  More  precisely,  we  are  interested  in 
understanding  how  different  DSS  affect  decision-making  processes  differentially.  The 
three-tiered  schema  should  prove  especially  useful  for  addressing  this  question,  because  in 
developing  the  schema  great  emphasis  was  placed  on  identifying  those  characteristics  of 
systems  that  are  determinants  of  decision-making  behavior. 

When  studying  the  effects  of  DSS  on  decision-making  behavior,  the  DSS  usually 
serves  as  the  independent  variable  and  we  concentrate  on  the  third  tier  of  the  schema. 

One  of  the  three  attributes--restrictiveness,  guidance,  or  focus--is  selected  for  study,  and 
the  other  two  attributes  are  held  constant.  Several  DSS  are  acquired  that  differ  only  in 
terms  of  the  attribute  under  consideration.  By  studying  the  decision-making  processes  and 
decisions  of  subjects  using  different  systems,  we  can  detect  the  effects  of  variations  in  the 
particular  attribute.  Of  course,  determining  which  aspects  of  decision-making  processes  to 
analyze  depends  on  the  specific  research  objectives. 

As  an  illustration,  consider  research  concerning  the  effects  of  DSS  on  systematic 
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cognitive  biases  in  decision-making  processes.  Researchers  in  Behavioral  Decision  Theory 
have  observed  that  human  problem  solvers  exhibit  a  number  of  systematic  cognitive  biases 
in  making  decisions.  That  is,  humans  systematically  misprocess  information--often 
probabilistic  information --in  performing  decision-making  tasks.  Literally  dozens  of  such 
biases  have  been  studied  in  the  literature  (Tversky  and  Kahneman,  1974;  Kahneman,  Slovic, 
and  Tversky,  1982;  Sage,  1981;  Hogarth  and  Makridakis,  1981). 

Several  researchers  have  raised  the  question  of  the  relationship  between  DSS  and 
cognitive  biases  (K.ydd  and  Aucoin-Drew,  1983;  Wright,  1983;  and  Schocken,  1985).  One 
question  we  can  consider  is  whether  computer-based  systems  may  in  fact  foster  some  of 
these  biases.  Another  question  is  whether  a  computer-based  aid  can  be  used  to  debias  a 
decision  maker--that  is,  to  offset  or  correct  for  the  biased  processing  of  information.  In 
particular,  one  might  hypothesize  that  particular  forms  of  DSS  restrictiveness  can  be  used 
to  reduce  biased  information-processing  by  proscribing  activities  that  can  lead  to  biased 
behavior.  A  researcher  could  examine  such  a  hypothesis  by  first  studying  the  biases 
exhibited  by  users  of  a  particular  DSS,  then  varying  the  restrictiveness  of  the  system,  and 
finally  studying  the  biases  manifest  by  users  of  the  revised  system. 

A  Prescriptive  Mapping.  The  descriptive  schema  proposed  here  represents  a  major 
step  in  the  direction  of  a  prescriptive  mapping  from  decision-making  environments  to 
Decision  Support  Systems.  Of  course,  considerably  more  research  must  be  performed 
before  we  will  be  in  a  position  to  offer  significant  prescriptions  concerning  what  types  of 
DSS  should  be  built  for  particular  types  of  decision-making  environments.  Indeed,  we  still 
must  find  an  appropriate  way  of  describing  and  differentiating  the  elements  of 
decision-making  environments;  the  people,  tasks,  and  organizational  settings.  The 
descriptive  mechanism  for  DSS  may  help  with  this  endeavor,  as  well,  by  providing  a  means 
for  evaluating  the  various  approaches  that  have  been  proposed  in  the  past  for  characterizing 
decision-making  environments.  Those  environmental  characteristics  that  are  shown  to  have 
meaningful  implications  in  terms  of  the  three-tiered  analysis  should  be  seen  as  the  most 
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promising  bases  for  prescription. 

Develonment  Systems  for  DSS.  A  number  of  different  software  approaches  can  be 
used  to  develop  DSS.  One  means  of  implementing  DSS  is  by  using  general-purpose 
languages  such  as  Fortran  and  APL.  Alternatively,  Sprague  (1980)  has  advocated  building 
specific  DSS  from  "DSS  Generators,*  packages  of  related  hardware  and  software  capabilities 
that  enable  builders  to  construct  DSS  quickly  and  easily.  More  recently,  Ariav  and 
Ginzberg  (1985)  have  identified  "Generalized  DSS,*  systems  that  provide  support  for  a 
particular  class  of  decision  problems,  as  another  resource  for  constructing  specific  DSS. 

The  three-tiered  schema  is  used  to  describe  specific  DSS,  not  the  development  systems 
from  which  they  are  created.  Two  open  and  important  research  questions,  therefore,  are 
how  to  describe  the  characteristics  of  development  systems  and  how  these  characteristics  of 
development  systems  are  reflected  in  the  DSS  they  produce.  More  specifically,  we  need  to 
know  how  the  functional  capabilities,  user  views,  and  system  attributes  of  a  DSS  are 
determined  by  the  characteristics  of  the  software  system  that  produced  it.  One  element  of 
such  research  is  to  understand  how  the  characteristics  of  existing  DSS  Generators  and 
Generalized  DSS  affect  the  DSS  they  produce.  Another  aspect  of  the  research  is  to 
consider  how  new  DSS  development  systems  can  be  designed  that  produce  DSS  with 
particular  features--for  instance,  DSS  with  non-trivial  sequencing  rules  or  DSS  with 
extensive  guidance. 

Artificial  Intelligence  Methods.  Recently,  the  DSS  community  has  expressed  great 
interest  concerning  Artificial  Intelligence  (AI)  techniques,  in  general,  and  Expert  Systems 
(ES)  and  inference  mechanisms,  in  particular.  For  DSS  researchers,  the  chief  question  is 
how  these  new  and  exciting  underlying  technologies  can  be  employed  to  build 
computer-based  systems  that  are  more  supportive  of  decision  makers.  The  descriptive 
schema  can  be  invoked  to  transform  the  issue  into  three  more  specific  questions. 

First,  how  can  AI  and  ES  techniques  be  used  to  create  new  functionality  in  DSS? 
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As  one  example,  an  inference  engine  together  with  a  suitable  knowledge  base  could  be 
used  to  analyze  historical  databases  and  identify  important  trends  for  decision  makers. 
Turban  and  Watkins  (1986)  have  surveyed  a  number  of  functions  that  Expert  Systems 
technology  can  perform  for  Decision  Support  Systems. 

Second,  how  can  AI  and  ES  techniques  be  used  to  implement  particular  components 
of  DSS?  Typically,  new  functionality  will  be  implemented  as  individual  operators.  But 
what  about  the  other  components  of  DSS?  Both  navigational  aids  and  sequencing  rules  are 
difficult  components  to  implement  and  are  prime  candidates  for  the  use  of  AI/ES 
methods.  Both  require  the  DSS  to  draw  context-sensitive  conclusions  and  could  be 
implemented  as  "mini"  production  systems.  For  instance,  a  navigational  aid  that  suggests 
which  operator  to  invoke  next  could  be  based  upon  a  set  of  production  rules.  These  rules 
might  be  defined  in  advance  by  the  system  builder  or  might  even  be  derived  by  the 
system  during  the  course  of  system  use.  Similarly.,  a  rule-based  system  embedded  within 
the  DSS  would  be  ideal  for  implementing  complex,  non-trivial  sequencing  rules. 

The  third  question  is  how  embedding  AI  and  ES  techniques  in  a  DSS  can  affect  the 
system’s  attributes.  For  instance,  when  a  "mini"  expert  system  is  built  into  a  DSS,  the 
expertise  can  be  implemented  in  the  form  of  restrictiveness,  imposing  results  on  decision 
makers,  or  in  the  form  of  guidance.  Similarly,  if  an  expert  system  is  implemented  as  a 
source  of  guidance  to  users,  that  guidance  may  either  be  in  the  form  of  pertinent 
information  intended  only  to  enlighten  the  decision  maker,  or  in  the  form  of  suggestions 
intended  to  influence  the  decision  maker.  These  alternative  approaches  to  embedding 
expert  systems  in  DSS  and  their  effects  require  more  extensive  study. 

7.  Conclusion 

The  three-tiered  descriptive  schema  presented  here  satisfies  the  objectives  set  forth  at 
the  outset:  enlightening  research  and  practice,  facilitating  communication  among  researchers 
and  between  researchers  and  practitioners,  distinguishing  as  well  as  describing  DSS,  and 
understanding  DSS  in  terms  of  their  effects  on  decision-making  processes.  At  each  level 
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of  the  schema,  the  descriptions  highlight  characteristics  that  distinguish  DSS  from  one 
another.  Each  analytical  level  also  considers  the  features  of  DSS  in  terms  of 
decision-making  behavior,  with  increased  attention  being  paid  to  the  effects  of  systems  on 
decision-making  processes  as  one  moves  up  the  tiers.  Moreover,  each  level  builds  on  the 
information  provided  by  its  predecessors. 

The  first  and  second  descriptive  tiers  are  the  ones  most  commonly  used  today,  with 
the  first  level  typically  receiving  greater  attention  than  the  second.  The  value  of 
describing  functional  capabilities— the  first  level— can  be  increased  by  augmenting  such 
descriptions  with  an  analysis  of  the  general  decision-making  needs  addressed  by  the 
information-processing  functions.  Similarly,  the  user  view  of  a  DSS--the  second  tier--can 
be  described  more  effectively  by  using  the  proposed  generic  user  view,  which  recognizes 
the  importance  of  navigational  aids,  adaptors,  and  sequencing  rules  in  addition  to  operators. 

The  third  descriptive  tier--system  attributes— represents  the  greatest  departure  from 
the  way  DSS  have  been  analyzed  to  date.  Studying  the  properties  of  DSS  considered  in 
their  entirety  is  critical  to  understanding  the  effect  a  system  will  have  on  the  processes 
through  which  decisions  are  made.  It  is  the  collective  effect  of  a  system’s  operators,  the 
synergistic  combination  of  a  set  of  packaged,  functional  capabilities,  that  is  of  primary 
importance  when  performing  either  ex  cmte  or  ex  post  analyses  of  the  effects  of  Decision 
Support  Systems  on  decision-making  processes. 

The  proposed  three-tiered  approach  is  a  first  step  toward  better  and  more  complete 
description  of  Decision  Support  Systems.  As  such,  it  highlights  many  of  the  substantive 
issues  in  the  field  of  DSS  and  can  serve  as  the  basis  for  significant  research  in  the  future. 
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